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(57) Abstract 

A bill editor, generator, messaging, and inseit system and method comprises a portion of a bill production processor (IS) designed 
to create monthly billing statements (28) which are sent to customeis and which detail charges incurred over the couree of a billing cycle. 
The bill editor and generator (ISI) allows UUIng personnel to design a bill using static text, dynamic text, and paragraph areas. Once the 
report/bill is defined, the report definition is stored in temporary memory for later use. The report definition file defines how the report is to 
appear and where the data used in the lepon is stored. The report generator, when subsequently nin, uses the predefined report definition 
to retrieve data from the database and generates the report as defined by the report definition file. The bill messaging and insert system 
(IS2, tS3) determines, based on assigned priority, criteria and weight and space limitations, the messages and notices to be included in a 
customer billing statement. 
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BILLING SYSTEM AND METHOD 

TECHNICAL FIELD OF THE INVENTION 

This invention relates in general to the field of data communication 
and more particularly to a system and method for the production of billing 
statements. ^ 
BACKGROU ND OF THE TNVFNTTnN 

Service and product providers must bill their customers. To do so, 
these service and product providers, such as cable television operators, local 
telephone service providers, long distance telephone providers, and credit 
card companies, must produce periodic billing statements for each of their 
customers, hi the case of a cable television operator, each customer receives 
a monthly billing statement. A single cable television company may operate 
numerous cable television franchises in several geographic regions, covering 
1 5 milUons of customers. Each of these customers receives a bUling statement 
each month. ^ j Jc^ 

Billing statements are often printed and mailed by bill renderers, 
which a service provider, such as a cable television operator, will contract 
to produce its billing statements. In this arrangement, the service provider 
20 often furnishes the bill renderer with the customer data to be printed on the 
billing statements. 

Prior to printing the bills, they must be generated, edited and 
appropriately messaged. As far as generating the bills are concerned, it is 
necessaiy to determine where on the customer billing statement the various 
25 textual information is to appear. Ideally, th e service or productp rovider 
u\ would Hke to have the flexibility to change the format of the billin g 

^A^ . statement without havi ng to physically type the textual infonn;.tinn frnn. 

scratch upon each change in the bill run format. Billing and reporting 
x\fir information traditionally has been presented in a fomat with little or no 
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flexibility for altering, without significant effort, the presentation of the 
information appearing on the bill or report. 

As far as bill messaging is concerned, it is necessary to include a 
variety of messages, notices arid inserts with the bill. However, there are 
5 limitations on how much material may be included on a standardized billing 
statement, which usually consists of a perforated sheet of paper, a portion of 
which is returned with payment. When all of the messages will not fit on the 
available space on the bill, some of the messages are merely omitted, 
regardless of priority or importance. There is no known system for 

10 prioritizing the universe of messages that could appear on a bill and then 
print them on the available space according to their priority. In addition, 
there are weight considerations which must be observed to avoid having the 
customer billing statement exceed the cost of first class postage. 

These and other considerations are addressed by the bill generator, 

15 editor and messaging system and method according to the preferred 
embodiment. 

SUMMARY OF THE INVENTION 

It an object of the present invention to provide a bill editor and 
generator which is flexible in its ability to modify the format of the customer 
20 billing statement. 

It is a further object of the present invention to provide a bill editor 
and generator which facilitates the process of bill editing and generating. 

It is a further object of the present invention to provide a bill 
messaging system which prints notices and messages on a customer billing 
25 statement according to a predetermined priority in the space allocated on the 
billing statement for such notices and messages. 
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It is a fiirther object of the present invention to provide a bill insert 
system which provides inserts to the customer billing statement according 
to a predetermined priority without exceeding the cost of the prevailing 
weight limit of the preferred ppstal class. 

These and other objects of the invention are accomplished by a 
report/bill editor and generator and messaging system and method of the 
preferred embodiments. The terms biU and report are used interchangeably 
and should be understood as such. The bill/report editor and generator 
system and method comprises a single module in die bill production 
processor. The report editor is a graphical editor which allows a report 
designer to use a palette of tools to customize where data is to appear on a 
report or bill. The report designer will decide how the report/bill will 
generally appear, and using the tools, create a graphical layout of where the 
textual infonnation will physically appear on the report. The report editor 
accesses database catalogs which contain table names, table column names 
and stored procedures. The report generator facilitates generation of reports. 

The report designer has at least three types of tools to generate the 
report's layout, static text tools, dynamic text tools and paragraph areas. 
Static text refers to elements such as labels and heading appearing in the 
report and their geometries and contents as well. Dynamic text refers to data 
retrieved from the database. The dynamic aspects of the report editor and 
generator refer to the order in which the paragraphs are to be generated in 
the report, and the stored procedures used to retrieve the data. Finally, 
paragraphs and paragraph areas refer to areas allocated on the report where 
repetitive infonnation is to appear. Once defined, paragraphs describe the 
mutual containment relationships of text. 
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Once the report editor has defined the layout of a report, a report 
definition file (RDF file) is stored in temporary memory. At some time in 
the future, the report may be run by a report generator program. The report 
generator program reads the RQF file from temporary memory. The RDF 
5 file describes how the report is to appear, where the data is stored and where 
it is supposed to draw the data on the report. The report generator queries 
the database under the control of the RDF file. The report generator pulls 
the data specified by the RDF file, and prints it in the maimer specified by 
the RDF file. The report generator, on user demand, uses a report defmition 

10 to get data from the database (and the user, if necessary) and generates the 
report defined by the report definition. The report generator can generate the 
report in any of the typical places supported on the native platform: screen, 
paper or disk. In other words, the user can specify that instead of printing 
the information on paper, it can be drawn in a win dow on a computer screen, 

15 or written to a file on a disk, which can be accessed at a later time without 
having to go back to the database. ^ — 
The bill message, notice and insert system and method comprises a 
bill defmition portion followed by a bill run portion. The bill defmition 
portion comprises a series of definitions which are input by the billing 

20 persoimel whereas the bill run portion determines which messages, notices 
and inserts eventually make it into the customer billing statement. More 
particularly, in the bill defmition portion, the billing personnel define the 
universe of available messages for a given billing cycle. The billing 
personnel also identify a universe of inserts available for the billing cycle. 

25 Each insert has a known weight. Next, the billing personnel define the 
criteria of information to be included on the bill. This could include account 
information, collections history, product history, etc. Next, the billing 
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personnel assign a priority to each of the messages, notices and inserts. In 
Other words, the billing personnel interact with a system to specify the types 
of messages, the criteria of information to be included in that particular bill 
run and the associated priority ^f the messages and notices. The system then 
processes this information- in the bill run portion to generate a bill which 
conforms to the weight and space limitations of the customer billing 
statement. 

More particularly, the bill run portion of the system then qualifies 
each message, notice and insert against stored information about each 
customer. Only messages, notices and inserts relevant to a particular 
customer qualify for that customer. The qualifying messages and notices are 
stored in temporary memory. Then, all of the qualifying messages and 
notices are airanged according to priority, and only those that fit on the bill 
are evenhially printed. At the same time, all of the qualifying inserts are 
stored in temporary memory. Only those inserts which, according to the 
predetermined insert priority, wiU make the final bill equal to or less than the 
weight limit of the preferred postal class are included in the customer billing 
statement. 

Other objects, features and advantages of the preferred embodiments 
will become apparent when the detaUed description is read in conjunction 
with the accompanying drawings. 
BRIEF DESCRIPTION OF THE DRAWTNriS 

FIG. 1 is a graphical representation of the preferred embodiment 
system of the present invention indicating the data flow of the generation, 
messaging and printing of a billing statement. 
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FIG. 2 is a graphical representation of the bill editor and generator 
module of the bill production processor according to the preferred 
embodiment. 

FIG. 3 is a flow representation of the biD editor and generator module 
according to the preferred enibodiment. 

FIG. 4 depicts a message generated by the bill editor and generator 
according to the preferred embodiment. 

FIG. 5 depicts a table generated by the bill editor and generator 
according to the preferred embodiment. 

FIG. 6 is a high level flow diagram of the bill messaging and insert 
system according to the preferred embodiment. 

FIG. 7 is a detailed flow diagram of the bill messaging and insert 
system according to the preferred embodiment. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

A service or product provider, such as cable television providers, 
local telephone service providers, long distance telephone providers, and 
credit card companies, store customer data on one or more databases within 
a customer management system. The customer management system 
manages the data comprising each customer account. As a customer's 
account changes over time, as a result of, for example, service and product 
orders and deletions, the customer management system updates the customer 
data so that an accurate current and historical record is maintained of each 
customer's account histoiy. FIGURE I is a graphical representation 
of a customer management system 10 of a service provider. A customer 
management system may include one or more data servers 12 connected 
across one or more communications links 13 to one or more customer 
databases 14. Databases 14 may be all located in one physical location or 
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may be located in separate physical locations. Each of data servers 12 is 
connected across one or more communications links 17 to a bill production 
processor 15, which processes and handles the customer data maintained in 
customer management systen^ 1 0. 
5 The bill production processor system 15 of the present invention 

includes a biU editor and generator module 151, a bill messaging extraction 
module 152, a bill insert manager module 153 and a bill fonnat manager 
module 154. All the customers of a service provider are not billed at the 
same time each month. A service provider will often bill its customers on 
10 a rolling monthly schedule so that different sets of customers, perhaps 
differentiated by geographic region, are each billed during different periods 
of each month. At the time of the month that a given set of customers is to 
be billed, bill production processor 15 extracts from customer databases 14 
die customer data that is to be printed on the billing statements provided to 
1 5 the billed customers. 

The input to the bill format manager module 154 is the unformatted 
customer data for each customer to be billed. The unformatted customer 
data provided at tfie output of bill fonnat manager module 154 includes 
account status infoimation. customer address infomation, account balance 
10 information, legal notices, promotional notices, and other data for each of 
the customers to be biUed. 

Bill fonnat manager module 154 receives the unfonnatted customer 
data from modules 151, 152, 153 and converts this data according to a bill 
Tenderer definition fonnat. The output of bill fonnat manager module 154 
5 is the formatted customer data for the set of customers to be billed. The 
output of bill fonnat manager module 154 is saved in a fonnatted customer 
baling file 20, which may be any suitable storage medium, including a tape, 
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disk, or optical storage medium. Fonnatted customer billing file 20 contains 
the formatted customer data for each of the customers to be billed. 

Fonnatted customer billing file 20 is provided to one of any number 
of available bill renderers .22| A bill renderer interpreter module 24 (I) 
inteiprets the syntax of fonnatted customer billing file 20, which is formatted 
according to the bill renderer definition format, (2) extracts the customer 
data fi-om formatted customer billing file 20, and (3) sends the interpreted 
and extracted data to a printer 26, which prints a series of customer billing 
statements 28. 

The output of biU format manager module 154 is formatted according 
to the bill renderer definition fomat. The bill renderer definition format 
provides a simple format for the service provider's customer data. The bill 
renderer definition format of the present invention is easily interpretable by 
the bill renderer interpreter module 24 of each of the service provider's bill 
renderers 22. 

With reference to FIG. 2 in conjunction with FIG.l, there is shown 
an overall schematic of the report editor and generator module 151. The 
terms "bill" and "report" are used interchangeably and should be understood 
as such. The report editor and generator has two separate components which 
work together to generate a bill. The first, report editor 15 1 1 , is the portion 
of module 151 directed to generating the graphical layout of a bill or report 
on paper gTascree al^he second, report generator 1512, is the portion of 
module 151 directed to die generation of report based on the instructions 
contained within report editor definition file 1513. 

A user, at 15 14, using a palette of tools defmes the overall layout of 
the report. When a particular tool is specified, whether it is static, dynamic 
or paragraph text, the report editor 1511 accesses database catalogs 1515. 


( 
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The editor accesses the database catalogs to allow the user to choose the 
stored procedures which are run when the report is generated. In other 
words, the user 1514 selects the stored procedures to be used by the report 
for execution at a later time^ Once the report is defined, it is stored in a 
report definition file (RDF file)1513. The RDF file 1513 is a temporary 
memory which stores the overall layout of the bill, but not specific customer 
data. 

When die billing personnel jesires to run a bill , the report generator 
segment 1512 of die system is tun. The report generator 1512 reads die RDF 
file 1513, which describes how the report it to appear, where in die database 
15 16 die customer data is stored and where to draw the data on the report. 
The report generator 1512 queries die database 1516 under die control of die 
RDF file 1513. The report generator 1512 pulls die data specified by die 
RDF file 1513, and prints it as a report 1517 in die manner specified by die 
RDF file 1512. The user can specify diat instead of printing die infonnation 
on paper, it can draw it in a window on a computer screen, or write it to a 


10 


15 


20 


25 


file on a disk, which can be accessed at a later time without having to go 

back to die database 1516. 

Widi reference to FIG. 3, diere is shown a schematic flow diagram of 

die steps used by die billing persomiel to edit and generate a report. Report 
^e gtori5rns first used to define die appearaii^r^f7hirepoftr5 'hen,7^rt 
ge nerator 1512 is used to collect die appropriate infon nation required by die 
r^ortdefiniti^ 151 3. In step 1560, die billiiiJ^^^^^ij^iZi^ut di e 
graphical elements which will appear on die bill. The,^ inri„H. ^^.^^ 
elements of step 1562, which consist of unchanging text, such as field 
captions, labels, headings, etc. In addition, in step 1564, dynamic text 
elements are input by die billing personnel. Dynamic text is text diat 
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depends on a table column or some other variable quantity, such as the 
current date, die current time, and page number. As is well known in the art, 
data in relational databases are organized in tables. For instance, the 
database may contain a customer table, which includes important 
5 information pertaining to die customer. Data in relational databases is 
generally organized in rows and columns. A specific customer in a customer 
Ajt/ft table is typically represented in a single row, along which all of the 
^ information about that customer is stored. The columns of the customer 
table might include first name, last name, customer ID, current balance, etc., 
10 respectively. 

Next, the billing personnel in step 1566 defines the paragraph area 
scripts. Paragraphs are generated widiin paragraph areas. A paragraph area 
appears widiin a larger paragraph. Each paragraph in the report is associated 
with a particular paragraph area in the report, and may only be generated 
15 within that paragraph area. A paragraph area is divided into one or more 
equal width columns. A paragr^h associated with a given paragraph area 
has a widdi equal to die width of eidier the paragraph area or one of its 
columns. The order in which paragraphs are to be generated in die report 
and the stored procedures diat are to be called to retrieve data are in a 
20 paragraph area script. 

Paragraphs are generated widiin paragraph areas under die control of 
the script. Associated witii each paragraph area is a paragraph area script, 
which constructs die paragraph area with die data obtained when die report 
generator 1512 queries die database 1516. The scripting language is 
25 preferably graphical, and diere may or may not be textual representation of 
it. One example of a textual representation of die scripting language syntax 
is shown below. When all paragraph areas in a containing paragraph are 
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full, and another paragraph is generated in one of the paragraph areas, 
another page is generated for the report. 

Once the report is defined by static, dynamic and paragraph text, it is 
reduced to an RDF file at 15^ and stored in temporary memory 1513. At 
some later time, the billing personnel can generate die report. Upon 
instruction to do so fi-om the billing personnel, the bill/report generator 1512 
reads the RDF file 1513, which describes how the report is to appear and 
where the data is stored in database 1516. The report generator 1512 
inteiprets the contents of the RDF file at step 1570 and at step 1 572 has the 
database execute stored procedures. Finally, the report generator 1512 pulls 
the data specified by the RDF file 1513, and prints it in step 1574 in die 
manner specified by the RDF file 1513. 

As is apparent from the foregoing, the RDF file is designed to 
providQupport for specification of all manner of printed output, fi-om 
15 traditiond^ line-oriented reports, such as pay-per-view order summaries, to 
forms, such as bills and work orders. The RDF file features easy 
specification of repetitive or one-time outputs in units called paragraphs, 
with a natural connection to data sets modeled as the result sets of stored 
procedure calls to a relational database. Advantageously, RDF files are 
20 amenable to graphical editing. 

The following is a listing of RDF syntax and semantics. It consists 
of an alphabetical listing of productions, each defining the allowable 
representations of some nonteiroinal. The syntax is presented in a very 
stylized form. Nonterminals are in angle brackets; tenninals are in boldface. 
25 Pseudoterminals are in italics, and are explained following die syntax. Text 
from a dash to the end of die line is commentaiy. Repetition of zero or more 
symbols is denoted by braces. Alternation between symbols is denoted by 
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10 


15 


20 


25 


a vertical bar. Numbers denoting origins and sizes are integer numbers of 
points, except where otfierwise indicated. There are 72.27 points per inch. 

With one exception, line breaks are significant in this syntax and 
appear where shown. The'texception is <page info>: due to space 
limitations, the representation of <page info> spans multiple lines, but in fact 
it must all appear on a single line. The distinguished symbol, i.e., the place 
to begin, is the nonterminal symbol <report>. 


<background color> 
<binding> 

<columns> 
<dynamic text> 


<element> 


<font> 

<foreground color> 
<full width> 


- Color 

- - an identifier denoting a data element 
(see Appendix A) 

- - number of columns in paragraph area 
= DynamicText 

<binding> 

<ori x> <ori y> <widtfi> <height> <justif> 
<backgroimd color> 
<foreground color> 
<font> 
= <dynamic text> 
<line> 

<paragraph area> 
<picture> 
<rectangle> 
<rounded rectangle> 
<static text> 
= Font 
- Cohr 

= " I if fiill width, 0 if column width 
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10 


15 


20 


25 


<grid size> 

<height> 

<justie> 

<landscape> 

<ltne> 


<margui bottom> 

<margin left> 

<tnargm right> 

<niargin top> 

<ori x> 
<ori y> 
<overlap x> 
<overlap y> 
<page info> 


= - granularity of editing grid 

- -height 

= - 0 if left, 1 if center, 2 if right 
= - 1 if landscape, 0 if portrait 

- Line 

<ptl x> <ptl y> <pt2 x> <pt2 y> 
<background color> 
<foreground color> 
= - paper bottom margin 

(nonintegral number of points) 

- - paper left margin 

(nonintegral number of points) 

- - paper right margin 

(nonintegral number of points) 
= - paper top margin 

(nonintegral number of points) 
= - X coordinate of origin 
= - y coordinate of origin 

- 0 
= 0 

- <page info version> <paper type> 
<landscape> <poster> <paper width> 
<paperheight> <margin leftXmargin 
right> <margin top> <margin bottom> 
<scale mode> <scale x> <scale y> 
<overiap x> <overlap y> 


<page info version> 


= a 
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<^aper height> 

<paper type> 
<paper width> 

<paragraph> 


<paragraph area> 


<paragraph identifier> 


<picture> 


<picture line> 
<poster> 
<ptl x> 
<ptl y > 


- - height of paper 

(nonintegral number of points) 
= PaperType 
' - width of paper 

(nonintegral number of points) 
= Paragraph 

<paragraph identifier> 
<full width> <height> 
<grid size> 

- number of elements 
{ <element> } 

= Paragraph Area 
<script> 

<columns> <ori x> <ori y> <width> 
<height> 

- number of paragraphs 
{ <paragraph> } 

- - a name uniquely identifying the 

paragraph within its paragraph area 
= Picture 
<ori x> <ori y> 

- number of picture lines 
{ <picture line> } 

- - 64 hex digits of Neuron Data image data 
= 0 

= - X coordinate of first point 
= - y coordinate of first point 
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<pt2 x> 
<pt2 y> 

<RDR version> 
<rectangle> 

5 

<report> 

10 

<rounded rectangle> 

15 

<scale itiode> 

<scale x> 
<scale y> 
20 <script> 

<static text> 


25 

<text> 


15 

- - X coordinate of second point 

- - y coordinate of second point 
= a 

= Rectangle 

<ori x> <ori y> <width> <height> 
<background color> 
<foreground color> 

- Report 
<RDF version> 
<page lnfo> 
<paragraph area> 

- RoundedRectangle 

<ori x> <ori y> <width> <height> 
<background color> 
<foreground color> 
= 3 

- 1 

- 1 

—a paragraph area script (see Appendix A) 
= StaticText 
<text> 

<ori x> <orl y> 
<background coIor> 
<foreground color> 
<font> 
= - static text 
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<width> 

Color 

Font 

PaperType 


16 

= - width 

= the name of a Neuron Data color resource 

- the name of a Neuron Data font resource 
1 US letter 

5 2 US legal 

3 US tabloid 

4 US ledger 
etc. 

Associated with each paragraph area is a script, defining how each 
10 paragraph area is to be rendered. The syntax of paragraph area scripts is 
shown below. It uses tiie same stylized form as the above RDF syntax. The 
distinguished symbol (that is, the place to begin) is the nonterminal symbol 
<script>. 

- <expression> 

15 <dataset> = <data set identified { <argiunent> } 

- Identifier 

- Identifier \ Number | String 
I <type> ( <expression> ) 

= foreach <data sef> 
20 { <statement> } 

end foreach 

- String 

= paragraph <paragraph identifier> 

- { <statement> } 

25 <statement> = <foreach statement>|<paragraph 

statement> 

<type> = integer ] Money | String | Time 


<argument> 
<data set> 
<data set identifier> 
<expression> 

<foreach statements 


<paragraph identifier> 
<paragraph statements 
<script> 
<statement> 
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Identifier = a sequence of one or more letters, 

digits, underscores, and periods, 
beginning with a letter, and not 
. matching any of the above 

boldfaced reserved words ~ may 
denote a data element, as <data 
set identifier>.<column name> 
Number = a sequence of one or more digits 

Effing - a sequence of zero or more non- 

quote characters, in quotes 
When a paragraph area is to be rendered, the statements comprising 
its script are executed, in sequence. Execution of a paragraph statement 
simply consists of rendering its identified paragraph, at the next location 
within the paragraph area. Execution of a foreach statement consists of two 
15 actions: 

I) Acquire the data set of the foreach statement. In online 
operation, this involves calling the identified stored procedure 
with the listed arguments. In offline operation, this involves 
reading die next data set from an input file, where the data set 
consists of a number of rows m, a number of columns n, n 
column names, and m rows of data, n columns per row. 
2) For each row in the data set, execute the statements of the 
foreach statement, in sequence. 
Two examples of a typical RDF file follow. The reports specified by these 
examples are shown in FIGS. 4 and 5, respectively. The fu-st example 
specifies a static message. 


20 
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RDF: 

Report 
a 

a I 0 0 614.295 794.97^2.27 72.27 72.27 72.27 3 1 1 0 0 
5 ParagraphArea 

paragraph "Paragraph 1" 

1 10 10 614 795 

1 

Paragraph 
10 Paragraph 1 

1 795 

6 
2 

StaticText 
15 Example 1: 

72 205 

Color.White 

Color.Black 

fonts. FontLarge 
20 StaticText 

The simplest report you'll ever need. 

72 229 

Color.Transparent 
Color.Black 
25 fonts.FontLarge 

The next example, the output of which is shown in FIG. 5, displays 
data in a paragraph area contained withm the top-level paragraph area. In 
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online operation, the stored procedure Ip _^et_subject_cat is the source of the 
data elements subject cat cd and subject cat desc. in offline operation, 
they come from an input file such as the one following the example. 
RDF: ^ 
5 Report 
a 

a 1 0 0 614.295 794.97 72.27 72.27 72.27 72.27 3 11 0 0 
ParagraphArea 
paragraph "Paragraph 1" 
10 i 10 10 614 795 

I 

Paragraph 
Paragraph 1 
1 795 
15 6 

4 

StaticText 
Example 2 
205 96 
JO Color.White 
ColorBlack 
fonts. FontLarge 
ParagraphArea 

foreach subject_cat paragraph "Paragraph 1" end foreach 
5 1 60 132 494 651 

1 

Paragraph 
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Paragraph 1 
1 36 
0 

3 . 
5 Rectangle 

20 0 468 37 

Color.White 

Color.Black 

DynamicText 
1 0 subjectcat. subject_cat_cd 

54 18 10 1 0 

Color.White 

Color.Black 

Font-Normal 
15 DynamicText 

subject_cat. subject_cat_desc 

271 18 11 1 0 

Color.White 

Color.Black 
20 Font.NormaI 

StaticText 

Code 

120 120 

Color.White 
25 Color.Black 

FontBold 

StaticText 


wo 97/24680 


PCT/US96/20135 


21 

Description 
337 120 
Color.White 
Color.Black ^ 
5 Font.Bold 

Input File: 

subjectcat 
10 11 2 

subject_cat_cd subject_cat_desc 
ADULT I Adult 
ADVEN I Adventure 
CHILD I Children 
15 CNCRT I Concert 

COMDY I Comedy 
DRAMA I Drama 
EDUC I Education 
FAM|Family 
20 HORRjHoiTor 

MUSCL I Musical Story 
SPORT I Sports 

With reference to FIG. 6 in conjunction with FIG. 1, there is shown 
25 a high level flow diagram of the bill messaging extraction module 152 and 
bill insert manager 153 according to the preferred embodiment. The bill 
messaging extraction module 152 determines die type of messages and 
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notices that may be included on a customer billing statement. The bill insert 
manager 153 determines whether inserts, if any, should be included within 
the customer billing statement based on the total weight of the bill In Step 
1501 of the bill messaging, notices and inserts process of FIG, 6, the user 
5 first defines a imiverse of messages, notices and inserts which could be 
included in the customer billing statement. Step 1301 allows billing 
personnel to enter all relevant messages, notices and inserts for a particular 
billing cycle, of which only a small subset may eventually appear in any 
particular customer*s billing statement. Thus, by initially inputting a 
10 universe of billing messages, notices and inserts, the billing personnel is 
relieved of having to generate customized billing statements for each 
customer 

In Step 1502, the universe of available messages are qualified for a 
particular customer, based on known criteria for that customer. If, of a 

15 universe of 50 messages, only 5 are relevant to, i.e., qualify for, a particular 
customer, the remaining 45 messages are discarded. 

Next, the messages and inserts are analyzed in Step 1503 to determine 
whether they will conform to the particular format established for that bill 
run. A particular bill format is chosen, perhaps consisting of a single, folded 

20 page, which is perforated so that the bill may be separated into two sections, 
one of which is returned with payment. All of the qualifying messages may 
not fit on the customer billing statement. Step 1503 determines whether 
particular messages will indeed fit on the chosen format for the customer 
billing statement. For instance, in the case of messages, this means that, of 

25 5 relevant messages, perhaps only 3 will fit on the final statement. Similarly, 
for notices, this means that only the most important notices will be included 
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in the bill, but only if the total weight of the bill is equal to or less than a 
designated postal weight, e.g., one ounce. 

Next, in Step 1504 all qualifying messages as specified through the 
formatting language transmi^ed to the bill Tenderer are printed and all 
qualifying inserts are stuffed into envelopes by the bill renderer. 

With reference to FIG. 7, there is shown a more detailed description 
of the bill modules 152, 153 according to the prefeired embodiment. The 
system may be seen as having two operating segments, the bill definition 
segment 1510 and the bill run segment 1520, one following the other. In the 
bill definition segment 1510, the universe of possible messages and inserts 
are defined by the billing personnel. Once the universe of messages is 
determined, the bill run segment qualifies the messages for each customer 
and executes a prioritization to determine whether a particular message 
and/or insert will be included in the customer billing statement. 

In Step 1512, the billing personnel defines for the billing period the 
universe of messages that could be included on any given billing statement 
without regard to individual customer information. The universe of 
messages are preferably input using a graphical user interface. Alternatively, 
an existing or flat file with a predefined universe of messages is accessed by 
the billing personnel, who then chooses which messages are to be included 
in the sub-universe of possible messages. The types of messages that might 
be included within the universe are varied. For instance, if a customer 
currently subscribes to HBO, one of the messages might include the 
promotion "Free Cinemax in the month of December for all HBO 
subscribers, Happy Holidays!" Alternatively, the messages might be notices 
or reminders. For instance, it might remind customers to call "1-800- 
DONTDIG" for assistance concerning where to dig on their property to 
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lb 



15 


20 



25 


avoid utility lines. Still further, the messages could be informational, such 
as inforaiing customers of rate increases/decreases, informing customers of 
deadlines for solicitation of comments concerning changes in rules, 
advertising for an upcoming pay^er-view event, collections messages such 
as "your account is past due of $45,00, please pay immediately,** etc. 

In Step 1514, the billing personnel identifies for the billing cycle the 
universe of inserts which could be included in any given customer billing 
statement without regard to individual customer information. The universe 
of inserts are input using the graphical user interface. The types of inserts, 
like the types of notices, are varied. For instance, they could include 
advertisements, legal notices, promotional coupons for local business which 
have paid for advertising on any of tiie cable stations, schedule of televised 
events, etc. 

After the universe of messages have been defmed and identified, the 
billing personnel in Step 1516 defines criteria for detennining which of the 
universe of messages, notices and inserts should be included in a particular 
bill nm. The criteria is preferably defined by the billing personnel using die 
graphical user interface. Alternatively, the billing personnel could access a 
flat file having a listing of possible criteria, which are then chosen according 
to relevance to the bill run. The criteria of messages is diverse, and could 
include, for example, account information, collections history, product 
history, instructions to send messages and inserts to all customersfonly to" 
-^p^cifieff customers or some otiier subset^f customers, ^instructions to send 

— ' — ! 

messages and inserts to those customers who have been late in remitting 
payment in the last three months, those in a certain zip codes, those 
subscribing to certain channels, etc., to name a few. The billing criteria is 
defined using traditional logic commands (AND/OR etc.) strung between tiie 
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various commands associated with the particular criteria. For instance, the 
criteria for a message could be designed as "All customers in franchise tax 
area 8010 AND in bill cycle 4 AND (have HBO OR Cinemax)". The step of 
setting specified criteria for a ^^iU run is particularly useful in the case where 
a limited bill run is scheduled for a segment of the franchise's customer 
base. The remaining segment of the franchise would thus be excluded from 
the bill run. 

In Step 1518, the billing personnel assigns a priority to each of the 
messages, notices and inserts using, e.g., a scale of 1-10. This qualifies die 
importance of a particular message, notice or insert and the likelihood that 
it is included in a bill nm. The higher the priority, the more likely a 
message, notice or insert will be included in a customer billing statement. 
For instance, government sanctioned legal notices would likely be assigned 
a relatively high priority, whereas advertising and promotional activities may 
15 be assigned a relatively lower priority. The billing personnel enters the 
priority of each of the messages, notices and inserts using the graphical user 
interface. With the conclusion of Step 1518, the bill definition segment 
15 10 is completed. No further input is required by the billing personnel. 

The bill run segment 1520 then commences. In Step 1522, each 
message, notice and insert, are qualified against stored information for each 
customer. Only messages, notices and inserts which are relevant to each 
customer individually qualify for that customer. For instance, if messages 
informing customers of imminent repairs in certain zip codes are included 
in the bill nm. customers of other zip codes do not qualify and messages and 
notices are not sent to tiiose customers in the non-qualifying zip codes. 
Alternatively, if Cinemax is offering a promotion, e.g., free Cinemax for 
customers with HBO, only those customers who cuirently subscribe to HBO. 


20 
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but not Cinemax, will receive the notice on their customer billing statement. 
It is possible that 50 or more messages, notice and inserts will have been 
defined, but only 5 or less qualify for a particular customer. 

In Step 1524, all of the qualifying messages and notices are grouped 
5 together. Based on formatting rules, the messages and notices with the 
highest priority are designated to be printed on the bill first. As described 
previously in connection with the bill editor and generator module 151, 
different message areas are defmed on the bill The formatting rules dictate 
that the highest priority message that can fit into these areas are included on 

10 the bill. Since die bill is typically a single, perforated sheet, a limited amount 
of text space is available. If all of the available space on the customer billing 
statement has been allocated to messages and notices of relatively high 
priority, any remaining lower priority, un-printed messages are discarded. 
Alternatively, any of the remaining lower priority, un-printed messages may 

15 be stored in the customer*s file for incorporation into the next billing run, 
and depending upon whether they are high enough in priority relative to the 
messages and notices for the next succeeding billing run and are not 
otherwise outdated, they may then be printed on the following customer 
billing statement. 

20 In Step 1526, all of the qualifying inserts are grouped together. First 

class postage is typically limited to a specified weight limited, e.g., one 
ounce. Anything above this will require further postage fees. When it is 
considered that tens of thousands of customers must be sent customer billing 
statements every month, the cost of mailing customer billing statements 

25 becomes significant. Thus, any deviation above the weight limit of fu-st 
class postage becomes economically significant on this scale. At the same 
time, however, if a number of inserts qualify for a particular customer, it is 
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desirable to include as many inserts as possible without exceeding the first 
class weight limit. Thus, in Step 1526, the qualifying inserts are chosen 
based upon the assigned priority until the total weight of the bill is equal to 
or less than the prevailing weight limit of the preferred mailing class, i.e., 
one ounce in the case of first class postage. Any of the remaining lower 
priority inserts which are not included in the customer billing statement may 
be stored in the customer's file for incorporation into the next billing run, 
and depending upon whether they are high enough in priority relative to the 
inserts for the next succeeding billing run and are not otherwise outdated, 
they may then be included in the following customer billing statement. 

Although the present invention has been described in detail, it should 
be understood that various changes, substihitions, and alterations can be 
made without departing from the spirit and scope of the invention as defined 
by the appended claims. 
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WHAT IS CLAIMED IS: 

1 . A method of preparing a customer billing statement comprising 
the steps of: 

defining at least ohe billing message to be included on the 
5 customer billing statement; 

defining criteria for including said at least one billing message 
on the customer billing statement; 

assigning a priority for each of said at least one message to be 
included on the customer billing statement; and 
10 qualifying each message for each customer based on stored 

customer information. 

2. The method of claim 1 further comprising the step of printing 
all qualified messages on the customer billing statement 

3. The method of claim 2, said printing step comprising the step 
1 5 of using formatting rxiles to print the highest priority messages that fit on the 

customer billing statement. 

4. A system for preparing a customer billing statement 
comprising: 

means for defining at least one billing message to be included 
20 on the customer billing statement; 

means for defming criteria for including said at least one 
billing message on the customer billing statement; 

means for assigning a priority for each of said at least one 
message to be included on the customer billing statement; 
25 means for qualifying each message for each customer based on 

stored customer information. 
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5. The system of claim 5, further comprising means for printing 
all qualified messages on the customer billing statement. 

6. A method of preparing a customer billing statement comprising 
the steps of: ^ 

5 identifying at least one insert to be included in the customer 

billing statement; 

defining an insert weight limit for limiting the total weight of 
inserts to be included in the customer billing statement; 

defining criteria for including said at least one insert to be 
1 0 included in the customer billing statement; 

assigning a priority for each of said at least one insert to be 
included in the customer billing statement; 

qualifying each of said at least one insert for each customer 
based on stored customer information; 
15 providing qualified inserts in the customer billing statement 

according to priority. 

7. The method according to claim 6 further comprising the step 
of limiting the weight of the customer billing statement, including inserts, to 
the maximum weight limit of a preferred postal class. 

20 8. The method according to claim 7, said limiting step comprising 

the step of limiting the weight of the customer billing statement, including 
inserts, to one ounce. 

9. A system for preparing a customer billing statement 
comprising: 

25 means for identifying at least one insert to be included in the 

customer billing statement; 
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means for defining an insert weight limit for limiting the total 
weight of inserts to be included in the customer billing statement; 

means for defining criteria for including said at least one insert 
to be included in the customer billing statement; 

means for assigning a priority for each of said at least one 
insert to be included in the customer billing statement; 

means for qualifying each of said at least one insert for each 
customer based on stored customer information; 

means for providing qualified inserts in the customer billing 
statement according to said assigned priority. 

10. A method of editing a customer bill comprising the steps of: 
defining at least one static text element to appear on the bill; 
defining at least one dynamic text element to appear on the 

bill; 

defining at least one paragraph script area on the bill, said 
static text elements, dynamic text elements and paragraph script area 
comprising a report defmition; and 

storing said report defmition as a report defmition file in 
temporary memory. 

11. The method of claim 10, said step of defining static text 
elements comprising the step of accessing database catalogues having a 
plurality of static text elements which can appear on the bill. 

12. A system for editing a customer bill comprising the steps of: 
means for defining at least one static text element to appear on 

the bill; 

means for defining at least one dynamic text element to appear 

on the bill; 
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means for defining at least one paragraph script area on the 
bill, said static text elements, dynamic text elements and paragraph script 
area comprising a report definition; and 

means for storing said report defmition as a report defmition 
5 file in temporary memory. - 

13. A method of generating a customer bill comprising the steps 

of: 

defming at least one static text element to appear on die bill; 
defining at least one dynamic text element to appear on the 

10 bill; 

defining at least one paragraph script area on the bill, said 
static text elements, dynamic text elements and paragraph script area 
comprising a report defmition; 

storing said report definition as a report defmition file in 
15 temporary memory; 

retrieving said report definition fi-om temporary memory; 
interpreting said report definition to determine customer 
specific information to appear on the bill; and 

retrieving customer information from databases to gather 
20 information to be printed on the bill. 

14. The method of claim 13, said step of defming static text 
elements comprising the step of accessing database catalogues having a 
plurality of static text elements which may appear on the bill. 

15. The method of claim 13, fiirther comprising the step of printing 
25 the bill to a screen. 

16. The mediod of claim 1 3, fiirther comprising the step of printing 
the bill on paper. 
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1 7. A system for generating a customer bill comprising the steps 

of: 

means for defining at least one static text element to appear on 
the bill; _ ^ 

5 means for defining at least one dynamic text element to appear 

on the bill; 

means for defming at least one paragraph script area on the 
bill, said static text elements, dynamic text elements and paragraph script 
area comprising a report definition; means for storing said report 

10 defmition as a report definition file in temporary memory; 

means for retrieving said report defmition fi-om temporary 

memory; 

means for interpreting said report defmition to determine 
customer specific information to appear on the bill; and 
1 5 means for retrieving customer information fi-om databases to 

gather information to be printed on the bill. 
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Example 1: 
The simplest report you'll ever need. 
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